In some current business applications, the term “activity” is used to refer to logic or code that modifies or transforms data. In a business application, the activity may be business logic, but could effect a transformation or modification of data in a different way. For example, an activity might simply create informational data and place it in a location for a user to view (e.g., a simple notification).
Business process workflows are performed using a particular sequence or arrangement of activities. Some current business applications sequence activities without wait points, while some other applications stall the sequencing of activities while the system waits for a human response (such as an approval of an invoice, etc.).
Current business software applications that deal with process workflows suffer from disadvantages. Most are focused on transactions involving business data rather than on dynamic and ever-changing business-related processes. Business processes are either hard-coded within application business logic or bolted on after the fact using proprietary or off-the-shelf workflow technologies. In other words, process workflows are not automated very well in some current business applications.
One reason that automated process workflows have encountered difficulty is that there is currently no strong semantic link between data, activity, and process workflow. There have been some attempts to automate processes, and they have typically been made by workflow application vendors. Such vendors commonly build add-on applications that try to drive processes. These are frequently separate software packages from the application for which the process is to be automated, and hence they may not be integrated at all, with the application and its data. Some such workflow applications attempt to establish integration with the data of the application, but many do not and those that do require manual work by those installing the workflow application.
Similarly, these types of add-on applications for automating a process have conventionally had their own, independent programming model that must be used to interact with and control the process and to manage data used by, or operated on, by the process. Even though an environment in which the automated process was deployed already had other mechanisms for these things, there was no integration with the environment. This required developers and other users to learn an additional programming model only for the process, which was inefficient and cumbersome.
There are also a number of current document management systems. Such systems receive a document and flow it to different parties, and then store it. However, such document management systems have conventionally been highly customized solutions which cannot easily be generalized for use in other areas. While they manage documents and flow, the documents store semi-structured data, which typically have few internal rules for how they are structured (e.g. a document in a word processor). Where such rules exist, they are not part of the process itself. In contrast, business applications typically have highly structured data and potentially many rules about how that data may change and how that data influences the flow of the process.
It can thus be seen that some processes have been automated in software. However, this was done in a rigid, technology implementation-specific way that is not easily adaptable to meet changing business needs or technology implementation requirements. These approaches were not integrated well with their environment and required users or developers to learn a new programming model. With such approaches, business processes cannot be easily or cost-effectively modified or replaced and process automation has come at the cost of business and technology flexibility and agility.
The discussion above is merely provided for general background information and is not intended to be used as an aid in determining the scope of the claimed subject matter.